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Chapter 1- VAXELN: Introduction and Overview. 


2 ■ VAXELN: Introduction and Overview 


WhatlsVAXELN? 

vaxeln realtime programming software is a powerful and sophis¬ 
ticated tool kit for creating specialized VAX software systems. It is a 
VMS optional product that runs on VAX superminicomputers and 
MicrovAX microcomputers and supports the development of 
stand-alone software systems. 

vaxeln systems include only those services (user programs or 
Digital-supplied programs) that are needed to support the func¬ 
tions of the system. In other words, systems are only as complex as 
they need be to do their work. We call such systems “statically 
defined.” 

Optimized for execution speed and efficiency, vaxeln programs 
are perfect for areas where general purpose systems just won’t do. 
This includes demanding realtime environments, dedicated dis¬ 
tributed processing, and other tasks in which processors have 
predetermined functions and are not needed simultaneously for 
general computing, program development, or other uses. Indus¬ 
trial automation, workstations, and Ethernet server networks are 
typical vaxeln applications. 

Although applications are by no means limited to realtime or 
networking jobs, vaxeln systems are most formidable in these 
areas. Especially suited to creating realtime applications, vaxeln 
software simplifies the design and implementation of such sys¬ 
tems. The conceptually simple, small object-oriented kernel exec¬ 
utive supplies basic runtime services efficiently. Optional service 
programs and device drivers implement a file system, network 
communication facilities, and i/o device handling, with mini¬ 
mum overhead. 
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It’s an Optional Product on VMS. 

The vaxeln Toolkit is an optional product that runs on a vax 
processor under the VMS operating system, Version 3.5 or higher, 
or under Micro VMS Versions 1.0 and 4.0. The tool kit consists of a 
compiler, System Builder utility, kernel executive, and debugger. 
During program development, several standard vms utilities are 
used like the VMS linker and editor utilities and the library facility. 

vaxeln applications run on VAX minicomputers and MicroVAX 
microcomputers, with no general purpose operating system 
present. The development system is called the vaxeln host 
processor: the execution system is called the target processor. Your 
finished vaxeln system can be loaded onto portable Files-11 b 
storage volumes and booted from them on the target computer. 
Or, if you have the optional DEcnet-VAX license and Ethernet 
hardware, they can be loaded downline into the target computer. 
Also, you can blast your application into read only memory for 
installation into the target system. 

The VAXELN System at a Glance. 

A vaxeln system is a set of programs executing on VAX hardware, 
along with standard code and data that manage the programs’ 
execution. 

You develop a new vaxeln system by writing whatever new 
programs are required in vaxeln PASCAL or using existing 
programs written in other vax/vms languages. Then, with the 
tool kit’s System Builder utility, you combine the programs— 
with each other, with any of the drivers and services you want, and 
with the vaxeln kernel—to form a functioning system. 
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vaxeln can combine one or more VAX or MicroVAX processors, 
optional peripheral devices (including disks and terminals), and 
communication hardware to support the execution of the pro¬ 
grams in a local area network. In addition, vaxeln hardware 
configurations can include special hardware you have designed or 
bought, such as custom device interfaces. 

If you are programming a set of computers linked by the Ethernet, 
you simply prepare a system for each computer, or node, and 
include the vaxeln Network Service in each node’s system. 

VAXELN Delivers Impressive Programming Results. 

With VAXELN you can obtain impressive programming results 
without becoming an expert at system programming, vaxeln 
tools let you bring your applications to life sooner by constructing 
concurrently executing programs for applications requiring maxi¬ 
mum efficiency and precise timing. And you can accomplish this 
without learning assembly-level programming. Instead, you can 
write your programs in PASCAL, an easy-to-use, high-level 
language. 

vaxeln PASCAL is a highly optimizing compiler, suitably 
extended to eliminate the need for other programming languages 
(including assembly language) in applications of this kind. It is the 
primary implementation language of the vaxeln tool kit itself. 
The vaxeln compiler can accept any iso-standard PASCAL 
program. 

vaxeln PASCAL is a superset of iso-standard PASCAL, extended 
for more power and versatility. 
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Concurrent PASCAL Makes Realtime Programming 
Possible. 

Both multitasking and multiprogramming are supported by the 
vaxeln kernel and vaxeln PASCAL programming language. 
Multitasking means that the user can declare parts of a PASCAL 
program even though they are concurrently scheduled for execu¬ 
tion with the main program. That is possible because the execu¬ 
tion of the task is interleaved with the execution of all other tasks 
on the same cpu, giving the effect of concurrent execution. 
Multiprogramming means that entire programs, including multi¬ 
tasking programs, can be scheduled concurrently on the same cpu. 

Convenience Features Make Application Development 
Quicker and Easier. 

vaxeln PASCAL offers several features that make programming 
more convenient. For instance, parts of a program can be written 
and compiled separately, without giving up any of the impressive 
typechecking features of the PASCAL language. This allows you 
to split up the work on a programming project, increasing 
productivity by assigning different programmers to work on 
separate sections. You can develop and debug your application 
code, module by module, adding each fully tested section to your 
total system as it is ready. 

Symbolic debugging lets you examine and modify a problem 
program using the PASCAL symbols you wrote it in. Once again, 
the fact that you use a high-level language makes you more 
productive. 
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Database Management with VAX Rdb/ELN. 

VAX Rdb/ELN is a relational database management system operat¬ 
ing in a vaxeln environment. 

By combining VAX Rdb/ELN with vaxeln and Ethernet you can 
create a fully functioning database management system that runs 
fast, costs less, and offers a number of unique features. 

See Appendix I for more detailed information about the relation¬ 
ship between vaxeln and vax Rdb/ELN, and some of the major 
features of VAX Rdb/ELN. 



Chapter 2- The Kernel. 
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The Kernel Is in Control. 

The vaxeln kernel is a layer of software between the hardware and 
your system software. It controls the sharing of system resources 
and synchronizes communication among the various programs in 
the system. 

In a simple, straightforward way, the kernel provides all the 
mechanisms necessary for a wide range of applications—for 
example, communication between processes. It also maintains all 
information about the system data and about the programs defined 
for a particular system. The kernel is delivered to you as a prepared 
image, ready to be built into a system along with your programs. 

Services and device drivers run independently of the kernel and 
user programs. They can be omitted from vaxeln systems that do 
not need their capabilities. This, in fact, is the model of a user’s 
vaxeln application in general: if the processes in a system or 
network require a complex service, it is provided as an independent 
program running in the system or network. For instance, a file 
server providing file storage hardware and software for a commu¬ 
nity of network users is built by constructing a vaxeln system 
from the Network Service, File Service, and disk driver and 
running the system on a network node that has the actual disks. 
vaxeln programs anywhere in the network can then use the file 
server without having to know its network location. 

Kernel Objects 

The kernel recognizes and operates on a number of objects in 
addition to the familiar entities (integers, strings, and so on) used 
in conventional programming. Each of these objects is represented 
in vaxeln PASCAL as a predeclared data type and has a corres¬ 
ponding set of operations realized in the language as procedure 
calls (see Appendix II). 
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Objects are created by CREATE procedures in vaxeln Pascal (for 
example, CREATE-PROCESS) and can be deleted by the generic 
DELETE procedure. The “ids” of objects—the value of the 
system types like PROCESS are valid everywhere in the creating 
job (see below) and, with the exception of PORT values, only in 
the creating job. In general, then, vaxeln systems are systems of 
independent process families (jobs) that exchange information 
only by message transmissions. 

With VAXELN the Process Is the Task. 

Processes are the execution agents for programs or for concur¬ 
rently scheduled parts of programs. (“Processes” compare to 
‘tasks” in other systems, such as rsx-11m.) the “main” program 
(program block) in a vaxeln PASCAL program is executed by a 
master process created implicitly by the kernel when the program 
is started, vaxeln PASCAL programs also can include special 
process blocks; these have the same form as a PASCAL procedure 
declaration, but with the word PROCESS-BLOCK in lieu of 
PROCEDURE. 

Process blocks are executed by dynamically created subprocesses. 
The programmer calls the CREATE-PROCESS procedure, spe¬ 
cifies the name of the process block, and receives a unique value of 
the data type PROCESS that identifies the process executing that 
block. (The master process, or any process, can obtain its own 
PROCESS value by calling another predeclared procedure.) 

In vaxeln terminology, the “family” of a master process and its 
subprocesses is a job. Jobs can be created dynamically (with the 
CREATE-JOB procedure) to execute a specific program that was 
included with the System Builder. One copy of a program’s code is 
shared by any number of jobs executing that program. A System 
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Builder option also allows the user to specify that jobs are created 
by the kernel, when the system is started, to run designated 
programs in the system and, as an additional option, to perform 
initialization sequences before other jobs are allowed to execute. 

Jobs running on the same processor are scheduled on a preemptive 
priority basis with 32 levels of priority. Within a job, processes are 
rescheduled the same way, but with 16 levels of priority. Both 
process and job priorities can be changed dynamically with kernel 
procedures. 

Processes can be explicitly removed from the rescheduling opera¬ 
tion with the SUSPEND procedure and reinstated with the 
RESUME procedure. Process rescheduling within a job can be 
temporarily stopped and then resumed with other kernel proce¬ 
dure calls. 

Each vaxeln process in a working system exists in one of several 
states: running, ready, suspended, and waiting. A high priority for 
a process means that it should preempt others in the same job 
when it is ready. Processes enter the waiting state when they call 
the WAIT-ANY or WAIT^ALL procedure to wait for other 
objects in the system. With WAIT_ANY, any of up to four 
object-arguments allows the caller to proceed; with WAIT_ALL, 
all four objects must allow the process to proceed. 

For example, a process can wait for a message to arrive at a port or 
for an event to be signaled by the SIGNAL procedure. By waiting 
for the PROCESS value that identifies a different process, a process 
can synchronize its execution with the termination of another 
process. 
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When the wait conditions are satisfied, the waiting process enters 
the ready state. Resumed processes reenter the state from which 
they are suspended. All processes are initially ready, and the kernel 
continually selects the ready process with the highest priority, 
giving it control of the CPU. 

Jobs are ready if they have at least one rdady process, and the 
highest-priority, ready job is allowed to run. As with processes, 
the running job is preempted if a higher-priority job becomes 
ready. 

The vaxeln kernel uses vax memory management to map user 
processes in the Program and Control regions of a 4-Gbyte virtual 
address space. The user stack is mapped independently into the 
control region for each process in a system. 

All other user code and data (including, for example, ‘ ‘heap’ ’ data 
managed by the NEW and DISPOSE procedures) are mapped in 
the program region, which is shared by all processes in a job. Data 
mapped into the program region can be either shared or unshared 
by a job’s processes, depending on how the user chooses to declare 
them in vaxeln PASCAL. 

The kernel does not support demand paging or swapping and, in 
fact, does not perform 1 /o to disks or other devices for any reason. 
Disks and their associated software are needed only when you 
want them for file storage. The vax page-fault mechanism is used 
only for dynamic extension of the user stack. The amount of 
physical memory on the target computer is the limit for the total 
size of instantaneously executable vaxeln processes running on a 
single processor. 




12 ■ The Kernel 


Communication and Synchronization Mechanisms Are 
Key to Concurrency. 

Concurrent processes can work successfully only if they manage 
their access to shared data and physical system resources such as 
disk storage. Processes communicate using several different 
vaxeln objects, including ports and semaphores. 

Ports are first-in/first-out queues of messages exchanged between 
processes in a vaxeln system. A port has only one receiver 
(“reader”), the job in which it was created. However, it can 
receive messages from any other process in the same vaxeln 
system or in the same network. 

In vaxeln PASCAL, the object is represented by the PORT data 
type. Its values include both an Ethernet address and object id 
thereby uniquely identifying the port to any process at any 
network location. The values of all other system objects are simple 
object ids that are meaningful only in their creating jobs. This 
means that vaxeln jobs can communicate only by sending 
messages to one another, not by sharing data or other means. A 
special port, the job port, is created implicitly when a job is 
created. 

By waiting for a PORT value, a process can synchronize its 
execution with the arrival of a message at that port. 

Names are user-defined names of ports. They ensure the transpar¬ 
ency of message-port locations in user programs. A NAME 
defines a text name and its translation, an associated PORT value. 
The kernel’s only NAME operation, other than creation and 
deletion, is the TRANSLATE_NAME procedure, which returns 
the PORT value associated with the text name. 
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When names are created, they can be specified as local or universal. 
A local name is meaningful only in its own native vaxeln system 
(that is, in its creating job and any other jobs running on the same 
network node). A universal name, however, is meaningful every¬ 
where in the network of vaxeln systems. 

The kernel in the caller’s system translates the local names. The 
translation (and maintenance) of universal names is a Network 
Service operation—one of the reasons why the Network Service is 
built into every system in a network application. 

In summary, the programs in the network can refer to message 
ports by translating names instead of by using explicit PORT 
values. Then, if programs are relocated in the network, only the 
name translations change. Since translations are performed by the 
kernel or Network Service, the code in the user’s programs is 
unaffected. 

Messages are transmissions between two vaxeln processes that can 
be processes in the same job, in different jobs, in different jobs on 
different network nodes, and so on. A MESSAGE indirectly 
specifies the sender’s port, the destination port, and the “text” 
(any data type) of the message. 

Events are synchronization objects used to coordinate execution of 
one or more system processes in response to a specific event. 

An EVENT object represents the occurrence of an event. Its state, 
cleared or signaled, remains the same until explicitly cleared by the 
CLEAR-EVENT procedure or signaled by the SIGNAL proce¬ 
dure. Other processes can await the event with the WAIT-ANY 
and WAIT_ALL procedures. When an EVENT object is sig¬ 
naled, all processes waiting for it become ready, if their wait 
conditions are otherwise satisfied. 
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vaxeln events are the same, in essence, as event flags in Digital’s 
vax/vms and rsx-11m operating systems. 

Semaphores are synchronization objects used to execute one process 
as the result of one signal. 

A semaphore acts as a gate controlling access to a resource. It 
maintains a count of the currently available units of the resource, 
such as the number of disk drives available, the number of gates 
available at an airport, or, in the case of an actual railroad 
semaphore, the “number of tracks’’ (0 or 1) available to a train 
going in a particular direction. 

You set the initial and maximum counts when you create the 
semaphore. The semaphore count interacts with the WAIT and 
SIGNAL procedures to control the execution of processes that 
wait for it. 

Unlike events, semaphores are changed by the action of the wait 
procedures. Specifically, signaling a semaphore increments the 
count, and, if a process continues as a result of signaling the 
semaphore, the semaphore’s count is decremented. A waiting 
process does not proceed unless the semaphore count is greater 
than zero. Together, these operations on the count mean that, at 
most, one process becomes ready when a semaphore is signaled. 

A process that wants to use the controlled resource waits for the 
semaphore. If the semaphore count is greater than zero, it is 
decremented, and the process is ready. If the count is zero, the 
process waits until some other process signals the semaphore. 
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A process signals a semaphore when it no longer requires the 
resource; SIGNAL increments the semaphore count. When the 
count is incremented, the first waiting process is allowed to 
proceed. 

Thus, the maximum count of a semaphore represents the available 
units of the resource being controlled. For example, if an auto¬ 
mated factory has 10 loading docks, truck access to the docks can 
be controlled with a semaphore whose maximum and initial 
counts are both 10. The initial count of 10 means that the first 10 
trucks will be allowed to proceed immediately to the docks. 

One process monitors the use of the docks by trucks and signals 
the semaphore whenever a truck leaves the dock. (Only one truck 
proceeds as the result of one signal.) Another process waits for the 
semaphore before allowing a new truck to proceed toward the 
dock, perhaps by raising a gate. 

With a maximum count of one, a semaphore can be used to guard 
a single item, such as a shared variable. This type of semaphore, 
also called a binary semaphore, can be used to prevent more than 
one process from simultaneously accessing the variable. 

The MUTEX data type and procedures for using it are also 
provided in vaxeln PASCAL. A MUTEX has the same general 
semantics as a binary semaphore except that a process does not have 
to call a WAIT procedure to determine whether the MUTEX is 
currently available. Using MUTEXES, a lock-unlock sequence 
(for example, getting and relinquishing access to a shared variable) 
consists of only four machine instructions. This can significantly 
reduce the time for the operation compared with the use of binary 
semaphores—typically by a factor of 10. Either binary semaphores 
or MUTEXES provide completely safe access to shared variables. 
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Device objects are used to synchronize a device driver program 
with the completion of an interrupt service routine. Interrupt 
service routines are written in vaxeln PASCAL. A declaration has 
the same form as a PASCAL procedure and the word 
INTERRUPT-SERVICE is used instead of PROCEDURE. 
They have two parameters: one defines the device registers for the 
device being driven, and the other defines a communication region 
in which the interrupt service routine and the driver program 
exchange all their information. The communication region is 
simply a dynamic data area that is accessible to both the job and the 
interrupt service routine because it is mapped in vax system space. 

A DEVICE value relates an interrupt service routine to a descrip¬ 
tion of the device created with the System Builder. The interrupt 
service routine (isr) is called by the kernel on the occurrence of a 
device interrupt and begins execution within two machine 
instructions of the interrupt’s posting. The isr can take any action 
needed to service the interrupt, using the device register pointer to 
gain access to the device registers. In the typical case of a device that 
interrupts for several reasons, the isr can examine the control status 
register to determine which interrupt has occurred. 

For instance, the isr can call SIGNAL-DEVICE to synchronize 
the main program with the interrupt. An isr can also handle the 
special requirements of devices after power failure. 

When the interrupt service routine has processed the interrupt, it 
calls the SIGNAL-DEVICE procedure. The driver program 
waits for this signal by supplying the DEVICE value to the 
WAIT^ANY or WAIT-ALL procedure. 

All the device drivers supplied with the tool kit are written 
exclusively in vaxeln PASCAL. As a guide to the user who must 
write new ones for other devices, sources are provided for each 
driver. 
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Using Objects 

Each system data type, or object, has a corresponding create 
procedure, which creates a new object of that type and defines its 
initial properties. For example, a program creates and initializes an 
event by the following kind of sequence. 


PROGRAM a; 

VAR 

proceed: EVENT; (EVENT variable} 

BEGIN 

CREATE.EVENT (proceed, EVENT$CLEARED); 

(Create an event value and assign it to proceed. The event is initially cleared.} 


END. 


Here, the EVENT variable proceed holds a new value created by 
CRE ATE_E VENT. 

Communication 

A set of message-passing facilities allows two processes to commu¬ 
nicate. Note again that, viewed from above, vaxeln applications 
are made up of message-passing jobs, and messages are the only 
means of communication between jobs. The resulting indepen¬ 
dence of jobs from each other’s databases means that they can be 
redistributed at will among nodes in a network, without chang¬ 
ing code. 
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For example, the File Service, Network Service, disk drivers, and 
user programs all are independent jobs in an operating vaxeln 
application. When a user calls the WRITE procedure in PASCAL 
to write a disk record, messages are transparently exchanged 
among the i/o runtime code, File Service, disk driver, and, in the 
network case, the Network Service and kernel. From the pro¬ 
gram’s and programmer’s viewpoint, it makes no difference 
where the disk is actually located in the network. 

Messages can be sent directly to a message port, or two ports can 
be bound together to form a circuit. Circuits have several desirable 
properties compared with unconnected ports: 

- Messages sent over circuits are guaranteed to arrive at the destina¬ 
tion in the order in which they were sent. 

■ Messages can have any length that the sender and the receiver can 

produce. If the transmission is across the network, the Network 
Service will divide the message into segments of the proper length, 
transmit the segments in sequence, and reassemble them at the 
destination node. 

■ Flow control prevents a fast sender from overwhelming a slow 
receiver. 

• Circuits can be “opened” as files, allowing PASCAL i/o proce¬ 

dures to be used for message transmission. 

No performance penalty arises from using circuits. And because 
their additional features are needed in most network applications, 
circuits are the recommended means of sending messages in most 
applications. 
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Message transmission between processes on the same network 
node does not involve moving data. Using VAX memory manage¬ 
ment, the memory containing the message is unmapped from one 
process and remapped to another. That means message transmis¬ 
sion is fast, predictable, and nearly independent of the message’s 
length. 

To send a message, you declare a pointer to the type of data you 
want to send and supply the pointer to CREATE-MESSAGE. 
The procedure dynamically allocates a data area of suitable size in 
the Program region, using the pointer’s associated type, and 
returns its address in the pointer. You then use the pointer to fill in 
the data area, obtain the id of the destination port, and, for the case 
of an unconnected message port, supply the MESSAGE and 
PORT values to the send procedure. For example: 


VAR mtext: TVARYING_STRING(80); 
command: MESSAGE; 
destination: PORT; 


BEGIN 

CREATE_MESSAGE (command,mtext); 
mtextt: = ‘START’; 


TRANSLATE_NAME( 

destination, 

‘SLAVE.PROCESSOR’); 
SEND(command, destination); 
END. 


The SEND procedure removes the data from your address space 
and places the message value in the destination port. 
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The receiver process waits for a message to arrive on its port and 
then uses the RECEIVE procedure to obtain it. The RECEIVE 
procedure automatically maps the message data into the receiver’s 
address space and returns a MESSAGE value and a pointer to the 
message data for the receiver’s use. 

If circuits are used, the sender establishes the circuit and then sends 
the message via the circuit: 


VAR mtext: TVARYING_STRING(80); 
command: MESSAGE; 
slave: PORT; 


BEGIN 

CREATE_MESSAGE(command,mtext); 
mtextt: = ‘START’; 


CONNECT_CIRCUIT ( 
slave, 

DESTINATION_NAME : = ‘SLAVE_PROCESSOR’); 
SEND(command, slave); 

END . 


The receiver process, in the circuit case, typically establishes one 
port—perhaps its job port—to receive connection requests and 
uses one or more other ports to form the circuits with other 
requesting processes. For example: 


VAR mtext: T VARYING_STRING(80); 
command: MESSAGE; 
myport, cport: PORT; 
myname: NAME; 




21 


BEGIN 

JOB _ PORT (myport); 
CREATE_NAME( 
myname, 

‘SLAVE_PROCESSOR’, 

myport, 

NAME$UNIVERSAL); 


(Wait for circuit requests, then connect cport in the circuit.| 
ACCEPT_CIRCUIT ( 
myport, 

CONNECT: = cport); 


RECEIVE(command,mtext, cport); 


(Interpret command.) 
END . 


Note that the receiver process must know beforehand the formats 
of all messages it expects to receive. That is, the sender and receiver 
must have established a message protocol. For example, if the 
receiver is a command interpreter of some kind, it must know a set 
of predefined commands to which it will respond. It can return an 
error message to the sender (or, more likely, to an operator’s 
terminal) if it receives a message that does not contain a valid 
command. Defining a protocol is the basic design task in 
interprocess communication. 



Chapter 3* Language: Powerful Programming in 
PASCAL. 
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Concurrent PASCAL Replaces MACRO Programming. 

The vaxeln PASCAL language is a compatible superset of the 
language defined in the International Standards Organization 
document iso/dis 7185. Any program written in iso-standard 
pascal can be compiled by the vaxeln PASCAL compiler and 
executed as part of the system. 

However, vaxeln PASCAL is really much more. It is supported by 
a highly optimizing compiler that generates position-independent 
VAX code. It has been extended to include data types and 
operations that support both concurrent and system program¬ 
ming. All of these enhancements add up to a high-level language 
that gives you the advantages of an assembly language such as: 
widespread access to the hardware, superefficient program execu¬ 
tion, and more. 

Special Data Types Enhance Programming. 

The general design principle for the compiler was to extend the 
language as little as possible to reflect the vaxeln kernel’s data 
types and operations, to provide a relatively small set of new 
features that enhance the standard language for system program¬ 
ming, and to completely eliminate the need for assembly language 
or any other language for vaxeln system programming. 

Language Extensions Make VAXELN PASCAL as 
Powerful as MACRO. 

The vaxeln Pascal language is further enhanced through language 
extensions such as the PROCEDURE-TYPE and FUNCTION 
-TYPE directives. With them you can declare the parameter 
types—and for functions, the result type—of entire categories of 
procedures and functions. Two such types are predeclared: 
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EXCEPTION-HANDLER and INTERRUPT-SERVICE. 
These features, in combination with others, such as the separate 
compilation features, allow you to construct abstract facilities, 
popular in modern languages like Modula II. 

Highlights of the language extensions are: 

■ Separate compilation allows large programs to be compiled as 
separate modules, without giving up PASCAL type-checking 
among modules. 

■ A generalized mechanism called flexible type, is provided for 
declaring data with parametric extents. Three such types— 
STRING, VARYING_STRING, and BYTE_DATA—are prede¬ 
clared for representing fixed-length character strings, 
varying-length strings, and series of bytes of uninterpreted data 
type, respectively. The flexible-type mechanism also is available for 
user-declared types. 

• Procedure and function parameters can be declared with confor¬ 
mant extents. For example, procedures can be easily written to 
handle arrays of any number of elements determined at compile or 
run time. 

• The user can apply the INLINE attribute to some procedure and 
function declarations, meaning that a “call” to the routine is 
expanded inline and does not result in an actual procedure call at 
the machine-language level. 

• Procedures and functions can have optional parameters and argu¬ 
ment lists of variable length. In addition, routines can be called 
with nonpositional argument lists. 
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■ The user can declare procedure types and function types. A 
function type, for example, represents a class of function that has 
arguments of the same type and that returns results of the same 
type. One such type, EXCEPTION-HANDLER, is prede¬ 
clared; its arguments are the standard VAX exception arguments, 
and its result type is BOOLEAN, where TRUE means that an 
exception was handled. 

- A number of features are provided for representing and manipulat¬ 
ing data exactly and conveniently in system programming prob¬ 
lems. Included are typecasting (allowing you to refer to a variable 
as if it had a specified type), a generalized CONVERT function, 
attributes to specify the machine representation and alignment of 
data predeclared procedures for operating on device registers, and 
the BYTE_DATA type. Also provided is the type t ANYTYPE, 
representing pointers whose associated types can be left unspeci¬ 
fied until they actually are used to refer to a data item in storage. 

■ Interrupt service routines are declared in the language in the form 
of a PASCAL procedure with the word INTERRUPT-SER¬ 
VICE in lieu of PROCEDURE. Interrupt service routines can be 
written in PASCAL (unlike vms, which requires that they be 
written in macro) and are evoked by the kernel on the occurrence 
of a device interrupt. 

- Process blocks are declared in the language in the form of a 
PASCAL procedure with the word PROCESS-BLOCK in lieu of 
PROCEDURE. Process blocks are activated by the kernel proce¬ 
dure CREATE_PROCESS; they are scheduled concurrently with 
the main program’s master process. 

■ The kernel data types DEVICE, EVENT, MESSAGE, NAME, 
PORT, PROCESS, and SEMAPHORE are predeclared data 
types in the language, with full data-type checking in effect. 
Similarly, kernel procedures are predeclared, with compile-time 
type checking applied to their arguments. 
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The MUTEX data type and support routines are provided as 
library declarations, significantly enhancing the performance of 
the binary semaphore. 

The QUEUE-ENTRY data type is provided, along with prede¬ 

clared procedures, for representing and using VAX absolute queues. 


A VAX/VMS Compatible File Service. 

The vaxeln File Service supports i/o operations from vaxeln 
PASCAL programs to file-storage devices such as disks, as well as 
remote file access from DECnet-VAX nodes. 1 /o requests from the 
user’s pascal programs (calls to the i/o runtime routines) are 
interpreted by the File Service and performed by the appropriate 
device-driver program. The File Service and the tool kit’s disk- 
driver programs use Digital’s Data Access Protocol (dap), Version 
7.0, as their i/o interface protocol. User-written drivers can run 
compatibly with the File Service by following this protocol, and 
programming tools are supplied in the tool kit for this purpose. 

The File Service uses the same on disk structure as vax/vms and 
the same internal file format as the vax Record Management 
Services (rms) . Accordingly, disk volumes from one environment 
can be read and written on the other, vax/vms file utilities can be 
used from a DECnet-VAX node to manipulate and maintain files on a 
remote vaxeln system. 

File Service files are organized sequentially, but can be accessed 
either sequentially or randomly. Random access FIND and 
LOCATE procedures are provided with vaxeln PASCAL. 

The File Service is not required for i/o to printers or terminals and 
it is omitted from vaxeln systems that do not need to operate on 
local files. 













Chapter 4- Developing a YAXELN Application. 
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Here’s a Complete Tool Kit for Specialized Software 
Development. 

The vaxeln tool kit, which runs on the VMS and MicroVMS 
operating systems, has everything you need to bring dedicated vax 
applications to life as quickly and efficiently as possible. 

vaxeln tools include the optimizing PASCAL compiler, the 
System Builder utility, and the symbolic debugger, vaxeln also 
includes extensive libraries of prewritten modules that provide a 
kernel of services for each vaxeln application, as well as prewritten 
device drivers, file handling routines, and the Network Service for 
transparent communication across an Ethernet local area network. 

VAXELN Applications Include Two Kinds of Programs. 

vaxeln applications are divided into two kinds: user programs 
most often written in vaxeln PASCAL and programs supplied by 
Digital. 

User programs can include user-written device drivers or resource 
services, as well as the normal computational programs. You never 
need to write in any language but PASCAL. 

Programs supplied by Digital include the File Service and Net¬ 
work Service. Also included in the tool kit are drivers for the 
commonly needed peripheral devices: disk devices, terminals, 
lineprinters, Ethernet controllers, and so on. Drivers are provided 
in source form; you can rewrite, adapt, or modify them to suit 
your needs. 

Developing a VAXELN Application, Step by Step. 

You develop a new vaxeln system by writing new vaxeln 
PASCAL programs or by using existing programs written in 
standard PASCAL. 
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If your PASCAL source file specifies a complete program, you can 
give the resulting object module directly to the VMS Linker utility 
to produce a program image. Otherwise, the object module can be 
used as input to later compilations, continuing until you have 
formed a set of object modules specifying the complete program. 
Then you can give the entire set to the Linker to prepare the 
program image. 

Then, with the tool kit’s System Builder utility, you form an 
operational system by combining the vaxeln kernel with the 
programs, using any of the drivers and services you want. The 
System Builder is a menu-driven program that runs under vax/ 
vms. It offers an extremely simple means of describing devices, 
programs, and overall system characteristics, especially compared 
with the long “system generation’ ’ dialog needed by many other 
realtime development systems. 

It’s surprisingly simple and straightforward to create a network of 
vaxeln systems for distributed processing. You build each system 
separately, including the vaxeln Network Service in each one, 
then connect them to the Ethernet by clamping a transceiver onto 
a cable. 

EDT: One of the Best Text Editors There Is. 

edt is an interactive text editor that’s easy enough for beginners yet 
powerful enough for experienced users. Using edt, the vax /vms 
text editor, you can create your vaxeln source-code files. It lets you 
do both screen editing and keypad editing on a Digital video 
terminal. 

With edt you can work on multiple files of text or programs 
simultaneously. Meanwhile, a journaling facility protects against 
loss of edits due to system failure. 
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The edt HELP facilities are extensive. You get help on general edt 
operations by typing HELP or pressing the HELP key in keypad 
mode. In keypad mode, common EDT functions can be performed 
on a separate set of keys. 

PASCAL Compiler Optimizes Code 

The PASCAL compiler does several different types of code 
optimizations to increase execution efficiency. The result is code 
that runs as fast as “hand optimized” machine code. Optimiza¬ 
tions include removing common subexpressions from statement 
sequences, placing local variables in multiple registers, removing 
nonvarying expressions from loops, and replacing certain code 
patterns with simplified code. All optimizations are optional; you 
can eliminate specific ones whenever you run the compiler. 

Separate Compilations and Flexible Libraries Increase 
Productivity. 

vaxeln provides PASCAL type-checking among separately com¬ 
piled modules. This means that it’s generally not necessary to 
compile everything needed by a module whenever a new feature is 
added to the program. As long as the same object modules are used 
in both compilation and linking, type consistency is assured. 

When a module is compiled, items declared at its outer level can be 
“exported,” allowing them to be used in other modules. Exported 
names, which by default are all the names declared at the outer 
level, are written in the object module in a special symbol table. 
When such an object module is included in the compilation of 
another module, the compiler reads the export symbol table to get 
declarations as needed. The symbol table has type information for 
each name, so type checking is retained among separately com¬ 
piled modules. The module heading also has import and export 
options that control the use of names between modules. 
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The vax/vms Librarian maintains libraries of modules, including 
object modules. The vaxeln compiler and vax/vms Linker both 
can use object modules stored in these libraries. 

Several libraries of runtime modules are supplied as part of vaxeln. 
These include, among others, the modules of the Data Access 
Protocol, the File Service, and the general math routines available 
in the language. 

Modules can be combined into shareable libraries so that, when 
more than one program image references them, there is only one 
copy of the code in the system image. 

The System Builder Utility Puts Your Application 
Together. 

After creating, compiling, and linking the programs that make up 
an application, you actually put the executable system together 
using the vaxeln System Builder utility. The System Builder 
combines one or more program images into a bootable system 
image. It also produces a system map, if desired, that lists all the 
images in the system, including their program descriptions, all 
devices with their device descriptions, all terminal descriptions, 
and all the system characteristics. 

Menu Driven, Simple Interface for Building a System. 

The System Builder includes an EDIT mode that displays a series 
of menus on VTlOO-series terminals. It lets you interactively tell the 
utility what programs, devices, terminal characteristics, and 
system characteristics you want. 

The main menu appears as soon as you enter the System Builder 
utility. From the main menu, you can build a system from the 
current data file information; edit the characteristics of the entire 
system; and add or edit descriptions of programs, devices, and 
terminal lines. 
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Configure Your System Quickly and Easily. 

With the System Builder, generating a vaxeln application system 
is just as fast as compiling a program. You select such menu items 
as Add Program Description and Edit System Characteristics, to see 
more specific menus and data screens. Then, modify the appropri¬ 
ate lines to suit your needs; the utility even checks your integer 
menu entries to see if they’re in the allowable range. You finish by 
returning to the main menu and selecting the Build System entry. 
The System Builder then automatically creates the new system 
image file and exits. 

The Symbolic Debugger Gets Your Programs 
Running Faster. 

There are two ways to debug your vaxeln applications. You can 
build the onboard debugger into your application and talk to it 
with the console terminal on the target machine. Or you can run 
the debugger on your host development system and control your 
target machine via an Ethernet link. 

Both vaxeln debuggers allow you to set breakpoints, evaluate 
expressions, examine program locations, and deposit values in 
locations. You can also introduce command definitions and 
variable declarations that are valid while you are running the 
debugger. 

The debuggers can display lines of source text during the debug¬ 
ging session, and traceback information will show the source-line 
number where an error occurred. Traceback information shows 
the recent execution history leading to the error. 

When you debug remotely from the host development system, 
you can refer to names of your PASCAL program variables and 
routines. 
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The appropriate debugger is built automatically into your system 
if you select the debugging option on the System Builder’s Edit 
System Characteristics menu. Selecting this option lets you debug 
your complete system, including other network nodes. 

VAX/VMS Operating System Is Your Host 
System Software. 

The vax/vms operating system has become one of the most 
popular in the superminicomputer industry. It is a powerful 
software base that organizes the great potential of the VAX 
hardware architecture. It provides priority scheduling of com¬ 
puter jobs, system management tools, and security and account¬ 
ing controls. There is a single set of commands for performing 
timesharing, realtime, batch, and interactive computing. 

The vax/vms System is highly reliable. Built-in protection mecha¬ 
nisms in both the hardware and software ensure data integrity and 
system availability. Online diagnostics and error detecting and 
logging verify system integrity. Many hardware and software 
features provide rapid diagnosis and automatic recovery, should 
power, hardware, or software fail. 





Chapter 5- Communication: Transparent Networks. 
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Transparent Communication Is Clearly Easier. 

In a network application, jobs on one system send messages to jobs 
on other systems across a local area network (lan). Jobs communi¬ 
cate either through the SEND procedure or through input/ 
output operations that use the services, drivers, and hardware of a 
different node. 

The vaxeln Network Service comes as a program image to be 
built into each system that participates as a node in the Ethernet 
network. The System Builder implicitly includes it when you 
select the remote debugging option for a system under develop¬ 
ment. 

The Network Service Makes Distributed 
Processing Simple. 

The Network Service in each node manages all message transmis¬ 
sions between Ethernet nodes (including those between vaxeln 
nodes and DEcnet-VAX nodes) and maintains a set of universal 
names among vaxeln nodes. One set of universal names is known 
throughout the network. Each Network Service uses universal 
names as unique identification for message sources and destina¬ 
tions. 

With the System Builder, the user can specify that the finished 
system’s node is eligible to be the name server for the vaxeln 
network. 

In an operating network, the “nominee’ ’ system with the highest 
Ethernet address is elected the name server. Each system retains the 
list of universal names it has created and listens for a periodic 
broadcast from the current name server. If no broadcast is heard 
during a specific interval, a new name server is elected, and each 
node sends the new server its list of universal names. This method 
helps preserve the integrity of universal names in the event of a 
name-server shutdown. 
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A vaxeln system is a DECnet end node. It can have one Ethernet 
datalink controller in its hardware configuration. The vaxeln 
system can communicate directly over the Ethernet with any 
DECnet-VAX node on the same Ethernet. If there is a full routing 
system on the Ethernet, it can communicate through the full¬ 
routing system with any other nodes in the entire network. 

Since both DECnet and Ethernet have a maximum message size, the 
maximum size of transmitted vaxeln messages, or datagrams, is 
specified as a System Builder characteristic. When circuits are used 
to transmit network messages, as described below, the Network 
Service segments messages. It divides long messages into data¬ 
grams of the proper size and transmits them in sequence. 

The Network Service and kernels on the network’s nodes tran¬ 
sparently communicate with each other to perform the DELETE, 
CREATE, and TRANSLATE operations on universal NAME 
objects. 

VAXELN Ethernet Operations Are Part of DECnet. 

The Network Service uses the Phase iv DECnet Network Service 
Protocol (nsp) and Session Control Protocol to provide transpar¬ 
ent application-level circuits to remote nodes, as described below. 
The Network Service’s nsp module then uses the routing module, 
also DECnet Phase iv, to deliver messages to remote systems. 

vaxeln DECnet nodes can be managed from vax/vms with the 
DECnet- vax Network Control Program (ncp). The vaxeln 
Network Management Listener (nml) provides a subset of 
DECnet Network Management to monitor the network and to 
control DECnet systems. 
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The Loopback Mirror can test the Network Service on a vaxeln 
node from a vms node or from another vaxeln node. It passively 
loops messages sent to it using the ncp LOOP NODE 
command. The Loopback Mirror is a good test of the Network 
Service’s ability to communicate with the rest of the network. 

Network Communication Is Transparent 

Transparent communication allows vaxeln and vms programs to 
exchange information using standard i/o statements, ignoring the 
fact that they are separated on the network. 

When one job sends a message to a job on another node, the 
Network Service locates the destination in the network and 
formats the message for transmission across the Ethernet. Neither 
the sending nor the receiving job communicates directly with the 
Network Service. Instead, the kernel on each node may determine 
that, for example, an outgoing message is not destined for any of 
the message ports on its node and forwards the message to its 
Network Service. Thus, when jobs on the same system exchange 
messages, the Network Service is not involved. In non-network 
applications, it can be omitted from the software system. 

Circuits Ensure Reliability. 

Binding two message ports together in a circuit provides the most 
reliable communication. The CONNECT-CIRCUIT procedure 
connects a sending message port to a specified destination port. 
The destination port accepts the request to link with ACCEPT 
-CIRCUIT. 

Circuits control the flow of messages between processes in the 
system, so you don’t have to program for it. Once a circuit has 
been established, the sending process automatically waits if the 
partner port contains its limit of messages. Using this technique, 
no sending process can overwhelm a destination port by sending 
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messages faster than the receiving process can accept them. This 
protects against unreceived messages “piling up” and consuming 
excessive memory in the system. 

Transparent Networking Makes Distributed 
Processing Painless. 

vaxeln applications can be run on stand-alone VAX and MicrovAX 
systems or, using networking software provided in the tool kit, 
connected in an Ethernet local area network (lan). The lan can 
include vax/vms nodes or any other nodes using DECnet-VAX 
services and protocols, vaxeln PASCAL programs can be redis¬ 
tributed unchanged among the nodes in a network. 

What is transparent networking? Suppose a network is made up 
of the nodes FRED, THOMAS, and MARION. A program on 
node FRED wants to talk to one on node MARION. In a 
nontransparent network, the program on FRED would have to 
know the network location of the receiver and, possibly, the 
network path needed to reach node FRED—for example, “I want 
to talk to THOMAS - MARION - receiver.” An improvement is 
to have network routing done by the system, although you still 
must know the receiver’s node—“I want to talk to marion - 
receiver.” In a completely transparent network, such as a vaxeln 
network, the statement is simply, “I want to talk to receiver.” 
That is, receiver can be identified by a universal name that, from 
the program’s viewpoint, is independent of the program’s actual 
location. 

Transparent networking makes vaxeln one of the simplest and 
most effective ways to implement multisystem applications. It 
makes server networks very straightforward. In a server network, 
some or all of the participant systems perform specialized func¬ 
tions for the entire network. For example, all disk devices and data 
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files might be concentrated at one node. Transparent communica¬ 
tion helps the whole network function smoothly with a mini¬ 
mum of programming effort. 

Ethernet Is the VA.XELN Communication Medium. 

Ethernet is easy, fast, and economical. It is the least expensive and 
most effective communication alternative for small geographical 
areas. It uses baseband signaling, as opposed to broadband signal¬ 
ing. Ethernet nodes transmit a large amount of information across 
a single, shared network channel using csma/cd access control. 

Transparent networking makes vaxeln a strong choice for distrib¬ 
uted processing applications such as server networks. With 
networking software provided in the tool kit, vaxeln systems can 
be connected in an Ethernet local area network, which may 
include vax/vms nodes or any other nodes using DEcnet-VAX 
services and protocols. You add each system to the network simply 
and directly; there are no complex configuration problems. 
Communication between systems is literally as simple as commu¬ 
nication between programs on the same system. 





Chapter 6- VAX Hardware: Systems of Choice. 
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The VAX Architecture Is a Proven Winner. 

VAX computers are high-performance multiprogramming com¬ 
puter systems ideally suited for a wide variety of applications, 
including realtime, batch, timesharing, and program develop¬ 
ment. The systems combine 32-bit architecture, efficient memory 
management, and a virtual memory operating system that pro¬ 
vides essentially unlimited program address space. 

VAX processors provide 32-bit addressing, sixteen 32-bit general 
registers, and 32 interrupt priority levels. All except the vax-11/ 
730 also include an efficient memory cache that increases program 
execution speed by reducing the need to access memory. 

The instruction set includes floating-point, packed-decimal arith¬ 
metic, and character-string instructions. Many of the instructions 
are direct counterparts for high-level language statements. The 
software system supports programming languages that take 
advantage of these instructions to produce extremely efficient 
code. 

The vax/VMS virtual memory operating system provides a mul¬ 
tiuser, multilanguage programming environment on the vax 
hardware. The floating-point instructions, efficient scheduler, 
and optional vax-11 fortran language (one of many available 
vax/vms languages) are ideal for realtime and scientific computa¬ 
tional environments. The information management services, 
large-capacity peripherals, and another optional language— vax- 
11 cobol —make the system equally suited to commercial applica¬ 
tions. 

To ease the sometimes complex task of configuring a computer 
system, Digital has developed the System Building Block (sbb) 
concept. Using it, you start with a basic system kernel, then 
choose other components from a menu. It offers an extremely 
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simple means of describing devices, programs, and overall system 
characteristics, especially compared with the long and compli¬ 
cated “system generation’ ’ dialogs needed by many other develop¬ 
ment systems. If you prefer to configure your system without 
using the sbbs, you can. 

VAX Systems Have Everything in Common. 

VAX architecture ensures software compatibility across vax sys¬ 
tems through common attributes such as addressing modes, the 
instruction set, and data types. 

The processor executes variable-length instructions in native mode 
and nonprivileged PDP-11 instructions in compatibility mode. 
Native mode includes the PDP-11 data types. It uses addressing 
modes and instructions similar to their PDP-11 counterparts, and 
the software supports compatible languages, and file and record 
formats. 

PDP-11 users will find the native vax- 11 instruction set and 
programming characteristics easy to learn when developing new 
applications for the vax system. 

Micro VAX Is Puts VAXELN to Work on 
Micro Applications. 

The Micro vax I computer, the first vax system on a Q-bus, allows 
vax users to realize the savings inherent in Q-bus options and 
packaging. Designed for realtime and timesharing applications, 
the Micro VAX I system is a low-cost, high-performance, 32-bit 
processor that is available in several configurations to allow 
customized system design for specific applications. 

The Micro VAX I computer is in the same performance class as the 
vax-11/730 and the pdp-11/44 systems. It is available with either 
256- or 512-Kbyte parity memory. 
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One of the challenges in producing the Micro vax I product was to 
reduce hardware costs yet maintain VAX-level performance. Part of 
the solution was to emulate some little-used instructions and data 
types using microcode-assisted software. The CPU hardware is 
especially designed to make this emulation so efficient that 
Micro vax I can give you vax performance at a size and price never 
before seen in a vax system. 

Specifically, decimal and packed-decimal math instructions were 
moved to software, as well as some string instructions. You choose 
a hardware double-precision floating point (d or g). The other is 
emulated, as is the 128-bit format (h). 

The MicrovAX architecture specifies that physical addresses can be 
up to 30 bits long. A physical address on MicrovAX I is 23 bits, 
allowing a physical address space of 8 Mbytes. 

MicrovAX is also fully software-compatible with the existing line 
of vax systems, when executing native-mode programs. Non- 
privileged native programs that run on a VAX processor today will 
run without change on the MicrovAX I. 

VAX-11/725: the Smallest VAX on the UNIBUS. 

The vax-11/25 system is Digital’s smallest unibus vax/vms 
system. It is a vax-1 1/730 computer packaged in an open-office 
cabinet along with the rc25 disk subsystem. Compact, quiet, and 
transportable, the vax-1 1/725 system supports up to eight users 
yet is only 40 percent of the physical size of the vax-11/730. This 
makes the vax-1 1/725 computer appealing as either a single-user 
workstation, an inexpensive multiuser system, or a network 
concentrator. 

It is available in three configurations with up to 3 Mbytes of 
memory. Options include a floating-point accelerator that gives 
users a faster, more efficient means of processing numerical data. 
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The rc25 disk subsystem, with a total of 52 Mbytes of storage, 
provides the reliability and performance of Winchester technol¬ 
ogy with the flexibility of removable media. Of the 52 Mbytes, the 
first 26 are on a fixed platter, while the remaining 26 are stored on 
an 8-inch removable cartridge. This allows the copying of disks at a 
one-to-one ratio. The fast backup also saves time and media costs. 
The rc25’s intelligent controller adds to the impressive perfor¬ 
mance of the vax-11/725 processor by offloading disk handling 
from the CPU. 

YAX-ll/730: When Expandability Is the Key. 

An ideal distributed processing network node, department-level 
host, stand-alone computer, front-end machine, remote concen¬ 
trator, or dedicated program development system, the vax-1 1/730 
computer is two-thirds the size and about half the price of our next 
larger processor, the vax-11/750. Our most flexibly configured 
VAX, the vax-11/730 system supports up to 24 users. 

Bit-slice and Programmed Array Logic (pal) technologies and 
advanced packaging combine to achieve dramatic economies of 
price and space. Choose a low-cost, rack-mountable chassis or a 
prepackaged vax-11/730 system. Or specify a vax-11/730 system 
from System Building Block (sbb) menu selections. Both the rack- 
mountable system and the packaged system include 1 Mbytes of 
memory (expandable to 5 Mbytes) and a 12-slot backplane. The 
sbb cabinet and menu systems include 2 Mbytes of main memory 
(expandable to 3 Mbytes) and nine expansion slots. In both cases, 
there are plenty of backplane slots for you to add the options of 
your choice, such as a floating-point accelerator that increases 
performance in engineering, scientific, laboratory, and other 
numeric intensive environments. The vax-11/730 supports a wide 
range of Digital-supported and customer-developed peripherals 
and communications devices. Your choice of system configuration 
and memory options determines expansion capability and price. 
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V\X-11/750: For More Demanding Work. 

The VAX- 11/750 computer is the midrange member of the vax 
family. Total software compatibility with other vax computers, 
impressive performance, and competitive price make it ideal for 
small firms and for individual departments within large organiza¬ 
tions—anywhere that large-system capability is needed by users 
with restricted budgets or workspace. The vax-11/750 computer 
supports up to 64 users in environments such as banking, educa¬ 
tion, and engineering, and it is the most economical way to start a 
VAXcluster configuration. 

Fewer components account for the reliability and low-cost of vax- 
11/750 hardware. Ninety percent of the vax-11/750 hardware 
logic is implemented in custom, low-power gate-array circuits. A 
single gate-array chip performs the functions of 25 standard 
integrated circuits. 

The CPU provides sixteen 32-bit user-programmable registers that 
can serve as temporary storage, accumulators, index registers, and 
base registers for user application programs. A virtual address 
space of 4 Gbytes allows large programs to be run without 
overlays. Depending upon the configuration, vax-11/750 systems 
can include up to 8 Mbytes of mos memory. 

The console subsystem consists of a tu58 cartridge tape drive and a 
dec writer terminal. 
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Options include a floating-point accelerator, extended-range 
floating-point microcode, additional memory modules of 1 Mbyte 
each (up to a total of 8 Mbytes), and memory battery backup. 

The processor has a 4-Kbyte, direct-mapped, write-through cache 
that greatly reduces effective CPU access time. The write-through 
feature protects the integrity of memory because memory con¬ 
tents are updated immediately after the processor performs a 
write. 

The optional User Control Store includes 10 Kbytes (1 Kbyte of 
80-bit microwords) of writable storage that allows customers to 
augment the speed and power of the basic machine with cus¬ 
tomized microcode functions. 

YAX-11/780: Power and Capacity for the Biggest Jobs. 

The vax-11/780 computer is the machine of legend, the standard 
by which all 32-bit machines are measured. The parent product of 
the entire family, it supports more than 100 users. As a stand-alone 
system or as part of a VAXcluster, the vax-11/780 gives you the high 
performance you need for data center processing. It can also be 
linked to other VAX systems in local-area or wide-area networks so 
that data can be accessed and shared by users throughout the 
organization. 

The basic system consists of the vax-11/780 cpu, 2 Mbytes of 
memory, a unibus expansion cabinet, and the vms operating 
system. Options include a floating-point accelerator, extended- 
range floating-point microcode, a writable control store and tools, 
up to 32 Mbytes of memory, and memory battery backup. 
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Proven Schottky ttl technology gives you the performance and 
overall system power that you need for your most demanding 
applications. 

Memory is expandable to 8 Mbytes of ecc mos memory (plus 4 
Mbytes of Multiport Memory). The ma780 Multiport Memory 
option can be shared by up to four vax-11/780 systems for high 
throughput. 

The 8-Kbyte cache memory, a key to the processor’s superior 
performance, delivers a 95-percent hit rate. An 8-byte instruction 
prefetch buffer further improves processor performance by prefet¬ 
ching and decoding data in the instruction stream. The control 
logic fetches longword data from memory to keep the 8-byte 
buffer full. 

The processor’s translation buffer contains 128 virtual-to-physical 
page address translations. This significantly reduces the time spent 
on such translations. 

In addition to sharing the identical set of system software with the 
vax-11/750 system, the vax-11/780 computer also offers compat¬ 
ibility with the peripheral set via the unibus and optional massbus 
adapters. Up to four unibus adapters can connect Digital- and 
user-designed peripherals, and a maximum of four massbus 
adapters can be used for connection of high-throughput disk and 
tape devices. 
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VAX-11/782 Attached Processor: Superior Performance 
for Multistream Applications. 

The vax-11/782 system has the power to run many large computa¬ 
tional jobs concurrently and still provide good response to termi¬ 
nal users. Technical, commercial, and OEM (original equipment 
manufacturer) users can, for example, run their largest programs 
on the system concurrently with interactive users. Additional 
applications include financial modeling, experimental data reduc¬ 
tion, file transfer, electronic and mechanical design using interac¬ 
tive graphics, and business forecasting. 

Consisting of two vax-11/780 CPUs linked through ma780 shared 
memory, the vax-11/782 system supports up to 8 Mbytes of shared 
memory. It is available as either a complete packaged system or as 
an upgrade for a single vax-11/780 computer. In many applications 
the vax-11/782 system doubles the performance of a single vax- 
11/780 computer—at a small incremental investment. 

All peripheral devices connect to the primary processor. The 
attached CPU provides additional computational resources, and 
applications can be transported to the attached processor without 
change. The assignment of tasks to a processor by the vax/vms 
scheduler is completely transparent to the user, so programmers 
can concentrate on their programs, not on where they’re being 
run. 
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VAX-11/785: The Top of the VAX Performance Line. 

The vax-11/785 computer, the newest member of our vax-11/780 
series, is also our most powerful single processor—giving you the 
fastest performance yet from the industry-standard VAX family. 
With added performance and variety, vax-11/785 configurations 
can serve more than 100 users and act as the host for a network. A 
large 32-Kbyte cache memory benefits users running applications 
such as cad/cam and simulation, wherein programs contain 
many complex subroutines. 

The vax-11/785 system increases the performance of the vax-11/ 
780 computer through advances in circuitry design. These 
advances speed data flow through the processor, improving 
response time for realtime applications and increasing the capacity 
for computation in compute-bound applications. 

Floating-point G and h data types are standard on the vax-11/785 
system and, as an option, you can add a floating-point accelerator 
for greater performance in numeric-intensive environments. 

VAXclusters: An Industry Original. 

A VAXcluster configuration is a unique multiprocessing system 
consisting of several VAX computers. Up to 16 vax-11/750 or vax- 
11/780 series processors and intelligent storage subsystems func¬ 
tion as a single powerful system. Supported by our versatile vms 
operating system, cost-effective VAXclusters offer resource sharing 
and an efficiency that is unmatched in the industry. Users can 
access any data in the VAXcluster, whether it is stored on local disks 
or on the hsc50 intelligent mass-storage subsystem. 

With several processors sharing the load, you gain speed, protect 
your data, and optimize disk storage. System advantages include 
redundancy to maintain data availability if a fault occurs; global 
data sharing for easy data updates and access, high performance, 
and multiple data paths that protect against downtime. 
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Choose from VAXcluster System Building Blocks to build a system 
to your exact specifications. VAXcluster systems permit expansion 
of the configuration, as needed, and without interruption of the 
existing systems or programs. Adding processing power or stor¬ 
age with a VAXcluster will expand your present system, preserving 
your investment. Or, if you are planning to buy your first VAX, you 
can start with one vax-11/750 or vax-11/780 series processor and 
add VAXcluster capabilities as your organization grows. You’ll be 
building a VAXcluster system that offers more protection for your 
data than has ever been available before. 




Chapter 7" Service and Support 
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Support That Equals Product Excellence. 

As you might expect, Digital’s Customer Services Organization is 
one of the largest and most effective in the computer industry. 
With hundreds of locations around the world and thousands of 
skilled professionals, Digital offers a wide range of services. 

Hardware and software specialists assist customers in analyzing 
and designing systems, in modifying Digital’s software to meet 
special needs, and in developing customer application software. 
They can create specific system designs using our standard prod¬ 
ucts or suggest alternate solutions for special situations. 

If a customer’s needs are not met by Digital’s standard offerings, 
Computer Special Systems analysts, engineers, programmers, and 
manufacturing specialists can be called in to help provide the 
necessary hardware and software. 

For your day-to-day operations, Digital maintains a complete line 
of supplies. Everything from magnetic media to word processing 
supplies can be ordered through our DEcdirect catalog, over the 
phone or by mail. 

For your other support needs. Digital offers a choice of software, 
hardware, and educational service programs. 

Service Contracts Tailored to Your Software Needs. 

To ensure continued software support and maintenance, Digital 
provides comprehensive system support services through two 
contractual agreements—Basic and DECsupport. These new pro¬ 
grams are available in the United States and will soon be available 
worldwide. Check with your Digital representative to determine 
availability in specific areas outside the United States. 
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Basic Agreement features include telephone support, software 
product and documentation updates, access to the Digital Soft¬ 
ware Information Network described below, and periodic news¬ 
letters. 

DECsupport is designed for customers who require uninterrupted 
system performance. It incorporates all services included in the 
Basic Service, plus the services of a software specialist, remedial 
support and scheduled preventive maintenance are also included 
for critical situations. 

Digital’s Software Information Network , part of the DECsupport 
package, keeps your staff informed of the most recent software 
information. When you dial into this online network, you have 
access to extensive databases containing the latest information 
regarding software solutions, answers to common software ques¬ 
tions, and examples of common usage situations. In addition, you 
can submit your software questions, concerns or solutions via the 
network so you and other customers can benefit from Digital’s 
expertise. 

With two clearly defined packages, you can suit your individual 
needs and budget. You will know, in advance, what your costs will 
be. This means you can budget accurately and be assured that you 
will get the level of software service and training you need for all 
Digital software. 

For most software configurations, the package cost will be 
significantly lower than purchasing the services and training 
separately. 
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Hardware Services That You Can Design. 

Digital’s hardware support services can also be sculpted to suit the 
needs of each customer. Two onsite agreements, Basic and 
DECservice, are available to vax customers. 

Basic service provides next day response and continuous effort of 
repair during coverage hours. Other features of this package 
include preventive maintenance, parts, labor, materials, installa¬ 
tion of engineering modifications, assigned service representa¬ 
tives, and a comprehensive site-management guide. Basic service 
also includes problem escalation, which establishes time frames for 
each level of service personnel attempting repairs. If the problem is 
not resolved within the allotted time, it must be referred to the 
next highest level for resolution. The process continues until the 
problem is solved. 

DECservice is a comprehensive onsite service package designed for 
the customer who requires up to 24-hour, 7-day-a-week coverage. 
Part of the agreement is a written commitment to respond to your 
call for service within a specified time. Scheduled preventive 
maintenance, parts, labor and materials are also provided. 

For vax-11/785, vax-11/782, vax-11/780, and vax-11/750 system 
users, Remote Diagnosis (rd) is a standard support feature. 
Customer Runnable Diagnostics (crds) is another service innova¬ 
tion available for vax-11/730 systems. 

For customers who maintain their own computers. Digital ser¬ 
vices include spares-inventory planning; maintenance documenta¬ 
tion service; spares, tools, and test equipment. Digital has also 
assembled well-defined spares kits and a recommended spares list 
that help customers establish proper spare-parts inventories. 
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Education Services Show You How. 

At 26 Training Centers around the world, Digital offers customers 
comprehensive educational programs to train personnel before, 
during, and after installation. 

Digest , a quarterly publication of Educational Services, contains a 
complete schedule of all the software courses offered at the North 
American Training centers. If you would like to receive a Digital 
DIGEST , contact your nearest Educational Services Training 
Center or ask your sales representative. 


For More Information . . . 

If you have more questions about vaxeln, contact your sales 
representative. For more information on related products, ask 
your Digital sales representative. Or if you prefer, write to: 

Media Response Manager 
Digital Equipment Corporation 
200 Baker Avenue CF01-2/M94 
Concord, Massachusetts 01742 
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VAXELN, Ethernet, and VAX Rdb/ELN Are 
More Than a Match. 

The combination of VAX Rdb/ELN, vaxeln and Ethernet provides 
a unique tool for establishing and maintaining a relational data¬ 
base. VAX Rdb/ELN, which does not require a general operating 
system, is a small, high-performance relational database manage¬ 
ment system that runs on vaxeln target systems and provides an 
alternative to the vaxeln sequential file system. It is part of the vax 
Rdb product set, which also includes vax Rdb/vMS. 

Using Rdb/ELN and vaxeln on an Ethernet local area network 
(lan) you can develop a database that is shared by multiple nodes. 

Without sacrificing CPU time or storage, or adding overhead, you 
can give every node on a network access to your database. The vax 
Rdb/ELN database also can accept data from different sources even 
if the data is organized in different ways. 

Because of the unique relationship between VAX Rdb/ VMS and vax 
Rdb/ELN, described below, you could even use databases on 
MicrovAX systems running vax Rdb/ELN to augment databases 
located on larger vax computers. 

Rdb/ELN for Time-Critical Applications. 

You can develop narrowly focused vaxeln realtime applications 
that take advantage of the small kernel executive, the vaxeln time- 
critical response, and the Rdb/ELN database management features. 

For example, a satellite passing over an earth station every 50 
minutes bursts large amounts of data in a short time to dedicated 
data collection computers. These processors (possibly PDP-11 and 
lsi-11) store the data in sequential files. 
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A MicroVAX, running Rdb/ELN, can be triggered by control 
information provided by incoming data. For example, the data 
collection devices signal vaxeln after every 20,000 records that it is 
time to invoke Rdb/ELN. Rdb/ELN then starts up a data storage 
process, loading the records from the sequential files into indexed 
relations for subsequent analysis. 

In this example, the programmer who designed the realtime 
collector system didn’t have to be concerned about the database 
interface because it is already included in VAX Rdb/ELN. Because all 
the database accesses are handled by vax Rdb/ELN on the 
MicroVAX, the programmer also didn’t have to worry about the 
collection process being interrupted by other systems trying to 
access the data during capture and thus losing incoming informa¬ 
tion. 

A Closer Look at VAX Rdb. 

vax Rdb is a family of relational database management systems 
that support the Digital Standard Relational Interface (dsri). 

Because of the dsri, programs written for a vax Rdb/vMS database 
are also vax Rdb/ELN database programs. This means an applica¬ 
tion running on a MicroVAX under vaxeln can access and use data 
from a vax Rdb/vMS database residing on any other vax. And 
applications designed to use data in a VAX Rdb/vMS database also 
can access data from a vax Rdb/ELN database. All current and 
future Digital relational products conform to this architecture. 

With their remote database management facilities, vax Rdb 
products can be configured with any combination of different- 
sized VAX computers to give you more options in designing your 
own solutions. Remote management features also mean that the 
user and the application program do not have to be located with 
the data; they can be anywhere on the network. 
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Like all vaxeln applications, Rdb/ eln programs and databases are 
developed on a host VMS system. When developing a new system, 
or when no vaxeln system is available, programmers can build a 
database on a VMS system for program development. When 
additional programs are added to an existing application, the 
development system can remotely access a database on a vaxeln 
system. The development option, which runs on the VMS operat¬ 
ing system, is priced separately from the target system license. 

What Makes a Relational Database System? 

A database management system is a package that allows con¬ 
trolled sharing of data, and helps protect data from corruption 
caused by system and program errors. Several users can update a 
database simultaneously without over-writing each other’s 
changes or seeing changes that might be temporary. Within a 
program, statements can be grouped into transactions. The 
database system insures that changes made in a transaction are all 
made or all undone cleanly. 

A relational database management system uses the relational 
datamodel. Data is stored in simple records, without repeating 
groups or variants. Records are grouped, by type, into relations. A 
relational database system includes normal storage and update 
operations (STORE, ERASE, MODIFY). The major retrieval 
operation in a dsri database is a for loop, which iterates over a 
group of records called a record stream. The records in the stream 
can be restricted with a SELECTION clause, which specifies 
values for fields, etc. A record stream can be made up of records 
from several relations, put together with a JOIN clause. Duplicate 
values can be eliminated from a stream with a PROJECT clause. 

• 9 "* 

One major advantage of dsri databases is that a program running 
on one node can access databases anywhere on the network. The 
remote interface is designed to reduce the network load for 
distributed applications. 




59 


Rather than passing relations or the whole database to the host 
program, the remote interface passes the request from the host to 
the database management system on the remote node, and returns 
the results, dsri and the common remote interface allow a single 
application to access databases running under VMS, Micro vms, or 
vaxeln software. 

And because VAX Rdb software lets you transport applications 
from one vax computer to another without modification, you 
gain flexible database management, flexible design, and the ability 
to distribute and balance application workloads in the most 
effective way. 

Some Other Vax Rdb Features. 

1. VAX Rdb can store unstructured data. Text, images, graphics, 
digitized voice, seismic data, any string of bytes of any size can be 
stored in a segmented string field in a database. Structured 
information identifying the string (time, date, read-out station, 
etc.) can be associated with the segmented string. 

2. Rdb/ELN includes a data definition compiler that creates 
databases and makes changes to database structures. If you are 
changing the database structure there is no need to make the 
database unavailable to other users or to unload and reload data. 

3. Rdb/ eln includes an interactive query language that is designed 
for low-volume data access and update, testing data manipulation 
algorithms, and learning to use the system. It includes online help, 
automatic command completion, and, when used remotely from 
the development vms system, a command and data editor. 
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4. Data manipulation statements are included in an ordinary 
EPASCAL program, freely mixed with native language state¬ 
ments. The vax Rdb/ELN EPASCAL PASCAL preprocessor 
recognizes the database extensions, translates them into database 
calls, and provides all the structures and buffers required. 

5. Unlike traditional database management systems, VAX Rdb can 
perform queries and support changing data relationships as 
requests are made by users and applications. 

6. Using the integrated data dictionary, the database can store and 
maintain definitions as they are created. The dictionary also makes 
it easy to restructure the database, and allows remote access 
requests to get at data definitions. This is especially useful, for 
example, when using vax datatrieve to access a remote VAX Rdb/ 
eln database. 

7. Validation rules for fields can be included in Rdb/ELN database 
definitions. When data is stored or modified, the database auto¬ 
matically verifies that the new data is valid. 

8. Rdb/ eln fields can also have a MISSING value delared. When a 
record is stored without specifying a value for some field, the 
declared missing value is used. The database system eliminates 
missing values from statistical computations like TOTAL, AVER¬ 
AGE, and COUNT. 

9. The data manipulation language, epilog, includes the relational 
database operators described earlier (STORE, MODIFY, 
ERASE, JOIN, PROJECT) and a very complete set of compari¬ 
son operators. In addition to the traditional = , <, ), ) = , 0> 
epilog includes BETWEEN and string comparitors CONTAIN¬ 
ING, MATCHING, and STARTING WITH. It also includes 
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arithmetic operators for addition, subtraction, multiplication, and 
division; a string concatenation operator; boolean operators; 
statistical expressions; and existence test; and a test for uniqueness. 

All these operations are performed in the database, reducing the 
amount of program code. Programs are easier to maintain and 
smaller, a real advantage in the vaxeln environment. 
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Table of Kernel Procedures. 

Call Format - Meaning 

ACCEPT_CIRCUIT (myport, 

FULL_ERROR: = boolean, 

CONNECT: = connect_port, 

ACCEPT_DATA: = varying_string, 

CONNECT_DATA: = varying_string, 

STATUS: = integer_variable) 

Establish circuit between myport and originator of connection 
request; if the full error is disabled (FALSE, default), SEND will 
wait implicitly when the partner port is full (otherwise, an error 
status is returned by SEND); the varying strings supply optional 
data to the originator (accept) or receive data (connect). The 
optional connect_port specifies a different port on which to make 
the actual connection. 

KER$ALLOCATE_MAP (status, register, number, count 
device_object, spt_address) 

Allocate count unibus map registers, beginning with register 
number, for device_object, and return pointer to first (ANY- 
TYPE) in register. The optional INTEGER variable status 
receives the completion status, and spt_address receives an ANY- 
TYPE pointer to the system page table base. 

KER$ALLOCATE_PATH (status, register, number, devi- 
ce_object) 

Allocate unibus buffered datapath for device_object, returning 
register number, and pointer to datapath register (ANYTYPE) in 
register. The optional INTEGER variable status receives the 
completion status. 
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ALLOCATE_MEMORY (mempointer, 
size, VIRTUAL: = address, 

PHYSICAL: = address, 

STATUS: = integer_ variable) 

Allocate size bytes of memory, beginning at virtual or physical 
address, and return ANYTYPE in mempointer. 

CLEAR_EVENT (event, 

STATUS: = integer, variable) 

Set state of event to 
E VENT$CLE ARED. 

CONNECT-CIRCUIT (myport, 

DESTINATION-PORT: - port, 

DESTINATION-NAME: = name, 

FULL_ERROR: = boolean expression, 

CONNECT_DATA: = varying.string, 

ACCEPT-DATA: = varying.string, 

STATUS: = integer, variable) 

Request circuit connection between myport and destination name 
or port; if the full error is disabled (FALSE, default), SEND will 
wait implicitly when the partner port is full (otherwise, an error 
status is returned by SEND); the varying strings supply optional 
data to the destination (connect) or receive data when the destina¬ 
tion accepts. (The destination must be specified, either by NAME 
or PORT value.) 
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CREATE_DEVICE (device_name, 
device.variable, 

VECTORJNfUMBER: = integer, 

SERVICE_ROUTINE: = isr, 

REGION: = rpointer, 

REGISTERS: = regpointer, 

ADAPTER_REGISTERS: = adpointer, 

VECTOR: = vpointer, 

PRIORITY: = integer_variable, 

POWERFAIL_ROUTINE: = isr, 

STATUS: = integer_variable) 

Connect to device_name interrupt and return the DEVICE value 
in device_variable. The vector number is an integer from 1 
(default) to 128. Interrupt service routines (isrs) can be supplied for 
interrupt and power recovery handling. The variable rpointer 
receives a pointer to the communication region: regpointer and 
adpointer receive pointers to the first device control register and 
first adapter control register, respectively; vpointer receives a 
pointer to the interrupt vector. Integer variables receive the 
interrupt priority level of the device and the completion status of 
the procedure. The device_variable can be a scalar DEVICE 
variable or an ARRAY [0..n] of device, where n<-16. 

CREATE_EVENT (event_variable, 
initiaLstate, 

STATUS: = integer, variable) 

Create an event with initialstate EVENTSSIGNALED or 
EVENT$CLEARED, and return EVENT value in event.varia- 
ble. 
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CREATE_JOB (port_variable, 
program_name,, argument-list, 

NOTIFY: = exit_port, 

STATUS: = in teger_ variable) 

Create a job running program_name, with optional arguments 
supplied to the program. The variable port_variable value receives 
the value of the new job’s job port. The value exit_port supplies a 
port that receives notification of the job’s termination. 

CREATE_MESSAGE (message_variable, 
data_pointer, 

STATUS: = integer_variable) 

Create a message with a data area suitable for the associated type of 
datapointer, and return the message value in message_variable. 

CREATE_NAME (name_variable, 
string, port, TABLE: = scope, 

STATUS: = integer_variable) 

Make string the name of port, with scope NAMESLOCAL 
(default) or NAME$UNIVERSAL, and return the NAME value 
in name_variable. 

CREATE_PORT (port_variable, 

LIMIT: = integer, 

STATUS: = integer_ variable) 

Create a message port able to hold up to integer (default 4) 
messages, and return the port value in port_variable. 
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CREATE_PROCESS (process.variable, 

process_block_name, 

argument-list, 

EXIT: = integer, variable, 

STATUS: = integer, variable) 

Create a subprocess running process.block.name, with optional 
arguments supplied to the subprocess, and return the process 
value in process.variable. Optional integer variables receive the 
final (exit) status of the subprocess and the procedure’s completion 
status. 

CREATE.SEMAPHORE (sem_variable, 

initial_count, 

maximum.count, 

STATUS: = integer.variable) 

Create a semaphore with the specified initiaLcount and max¬ 
imum.count, and return the SEMAPHORE value in sem_varia- 
ble. 

CURRENT.PROCESS (process.variable, 

STATUS: = integer.variable) 

Return the value of the current process in process.variable. 

DELETE (system.value, 

STATUS: = integer.variable) 

Delete the DEVICE, EVENT, MESSAGE, NAME, PORT, 
PROCESS, or SEMAPHORE value from the system. 
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DISABLE_ASYNCH_EXCEPTION 

(STATUS: = integer_variable) 

Disable delivery of asynchronous exceptions to the current pro¬ 
cess. 

DISABLE_SWITCH 

(STATUS: = in teger_ variable) 

Disable process rescheduling in the current job. 

DISCONNECT_CIRCUIT (port, 

STATUS: = integer, variable) 

Break circuit, where port is the one in the current process. 

ENABLE_ASYNCH_EXCEPTION 

(STATUS: = integer.variable) 

Allow delivery of asynchronous exceptions to the current process. 

ENABLE.SWITCH 

(STATUS: = integer.variable) 

Resume process rescheduling in the current job. 

EXIT (exit.status: = integer, 

STATUS: = integer.variable) 

End current process, with optional integer exit status delivered to 
creator. 

KER$FREE_MAP (status, count, 
number, device.object) 
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Free count unibus map registers previously allocated by ALLO- 
CATE_MAP. The optional status is an INTEGER variable. 

KER$FREE_PATH (status, number, 
device_object) 

Free unibus datapath number, previously allocated for device_ob- 
ject by ALLOCATE_PATH. The optional status is an INTEGER 
variable. 

FREE_MEMORY (size, virtuaLaddress, 

STATUS: = integer_variable) 

Free size bytes of memory at virtuaLaddress, previously allocated 
by ALLOCATE_MEMORY. 

GET_TIME (large_integer_variable, 

STATUS: = integer_variable) 

Return current time in large_integer_variable. 

INITIALIZATION_DONE 

(STATUS: = integer_variable) 

Inform kernel that current process has completed initialization 
sequence. 

JOB_PORT (port_variable, 

STATUS: = integer_variable) 


Return port value of current job port in port_variable. 




69 


RAISE_EXCEPTION i(argument-list, 

STATUS: = in teger_ variable) 

Raise exceptions in current process. 

RECEIVE (message_variable, 
pointer.variable, port, 

SIZE: = integer, variable, 

DESTINATION: = port, variable, 

REPLY: = port, variable, 

STATUS: = integer.variable) 

Receive message from port, return its MESSAGE value in messa- 
ge.variable and a pointer to its data part in pointer.variable; 
integer variables optionally receive the data area’s size in bytes and 
the procedure’s completion status; port variables optionally 
receive the destination port specified by the sender and a port for 
replies. 

RESUME (process, 

STATUS: = integer.variable) 

Resume rescheduling of previously suspended process. 

SEND (message,port, 

SIZE: = size, 

REPLY: = port, 

STATUS: = integer.variable) 

Send message to port, optionally specifying the data area’s size in 
bytes and a port for replies. 


SET.JOB.PRIORIT Y (integer, 
STATUS: = integer.variable) 
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Set priority of current job to integer (0_31, 0 highest). 

SET_PROCESS_PRIORITY (process, 
integer, STATUS: = integer_variable) 

Set priority of process to integer (0_15, 0 highest). 

SET_TIME (nonnegative_large_integer, 

STATUS: = integer_variable) 

Set current time to nonnegative_large_integer. 

SIGNAL (value, 

STATUS: = integer_variable) 

Signal value of type EVENT, SEMAPHORE, or PROCESS. 

SIGNALJDEVICE 

(DEVICE_NUMBER: = integer, 

STATUS: = integer_variable) 

Signal DEVICE value from interrupt service routine; the integer 
optionally supplies the index of the value to signal in an ARRAY 
[l..n] of DEVICE, where n<-16. 

SUSPEND (process, 

STATUS: = integer_variable) 

Suspend rescheduling of process. 

TRANSLATE_NAME (port_variable, 
string, scope, 

STATUS: = integer_variable) 
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Translate string, searching in scope NAMESLOCAL, 
NAME$UNIVERSAL, or NAME$BOTH, and return the asso¬ 
ciated PORT value in port_variable. 

VKAIT_ALL (system, value-list, 

RESULT: = integer_variable, 

TIME: = large_integer, 

STATUS: = integer, variable) 

Make calling process wait for all DEVICE, EVENT, PORT, 
PROCESS, or SEMAPHORE values in system.value-list to 
satisfy the wait. Zero to four system values can be specified; the 
optional integer.variable receives 1 if the system values satisfied 
the wait or 0 if the procedure timed out. The optional large.inte- 
ger specifies a time interval or absolute time defining the timeout; 
the timeout is irrelevant, and the wait result is 1, if the necessary 
conditions were satisfied before the call. 

WAIT^ANY (system.value-list, 

RESULT: = integer, variable, 

TIME: = large_integer, 

STATUS: = integer, variable) 

Make calling process wait for any value in system.value-list to 
satisfy the wait. If more than one system value is specified, the 
optional integer.variable receives the position of the argument 
satisfying the wait or 0 if the procedure timed out. The optional 
large_integer specifies a timeout as for WAIT^ALL. 
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The Lineprinter Driver. 

The program lcdriver supplied with the tool kit shows several 
features of vaxeln PASCAL, how the kernel is used from it, and 
the typical structure of device drivers—especially the interface to a 
requesting program. 

The overall structure of the program is: 


module lcdriver; 
include $dap, $unibus; 

const 


type 


var 


program Ipdriver; 

(Block.) 

interrupt_service powerfail.recovery(...); 
(Block.) 

interrupt, service printer, interrupt...); 
(Block.) 

end; (End of module.) 
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The module and end enclose a single compilation unit for the 
compiler, containing, in this case, a program block; constant, 
type, and variable declarations; and two interrupt service routines. 
The items declared at the module’s outer level (that is, outside any 
block) are usable everywhere in the module. Interrupt service 
routines must be declared at the outer level. 

Separate Compilation Allows Shared Modules. 

When a module is compiled, items declared at its outer level can be 
“exported,” allowing them to be used in other modules. Exported 
names, which by default are all the names declared at the outer 
level, are written in a special symbol table in the object module. 
When such an object module is included in the compilation of 
another module, the export symbol table is read by the compiler to 
get declarations as needed. The symbol table has type information 
for each name, so type checking is retained among separately 
compiled modules. The module heading also has import and 
export options that control the availability of names between 
modules. 

The words $dap and Sunibus are the names of other previously 
compiled object modules that contain declarations used in this 
one. They are, respectively, the declarations of Data Access 
Protocol (dap) interfaces and of support routines for writing 
unibus device drivers. 

Attributes. 

The type section, among other things, declares the types of several 
device control registers and of the communication region used by 
the driver and the interrupt service routines: 
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type 

byte = 0..255; 
word = 0..65535; 

csr = [word] packed record 

print_en : [pos(0)] boolean; (printer enable} 
reset: [pos(1)] boolean; (master reset) 
format: [pos(2)] boolean; (format flag) 
unused 1 : [pos(3)] boolean; (bit 4 unused) 
maint: [pos(5)] boolean; (maint bit) 
int_en : [pos(6)] boolean; (interrupt enable) 
ready : [pos(7)] boolean; (printer ready) 
imum : 0..7; (indirect register number) 
cverf: [pos( 12)] boolean; (cable verify) 
daverr: [pos(13)] boolean; (davfu error) 
lpt_err: [pos(14)] boolean; (line printer error) 
nxm_err: [pos(15)] boolean; (nonexistent memory) 
end; (record) 


register_ptr = tlpt_ registers; 

comm_ region = record 

csr_ response : csr; 
bytes_output: word; 
lines_output: word; 
base_vector_address : integer; 
powerfail: boolean; 
device_busy : boolean; 
end; (record) 

region_ptr = t comm_region; 


The attribute [WORD] means that the entire packed record is 
contained in a 16-bit word. [POS] means that the field begins at 
the given bit offset from the record’s base. 





15 


Main Program. 

The program obtains the name of the lineprinter controller it is to 
access from its argument list. The user supplies the name with the 
System Builder when the driver is built into the system. 

The name is then used in the CREATE-DEVICE call, which 
creates the device value used to synchronize the program with 
lineprinter interrupts (the value is returned in the printer-device 
parameter). As part of the operation, the kernel uses the controller 
name to locate the system’s description of the printer device 
interface, created by the System Builder. 


program Ipdriver; 

[INLINE] procedure initialize_interface; 

... (Block.) 

function open_printer of type dap$open_action; 

...{Block.} 

function write_printer of type dap$put_action; 

...{Block.) 


begin 

{Get the name of the controller) 
controller_name : = program_argument (1); 

{Create the device) 
create_device (controller_name, 
printer, device, 

vector.number : = lp_vector_number, 

vector : = vector, 

region : = region, 

registers : = register, location, 

priority : — printer, ipl, 

service, routine : = printer, interrupt, 

powerfail. routine : — powerfail. recovery); 
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A device description consists of the address of the device’s first 
control/status register (returned in register-location), the address 
of the device’s interrupt vector (returned in vector), and the 
interrupt priority level (returned in printer_ipl). The procedure 
creates a communication region large enough to hold a data item 
of type comm_region and returns its address in the region 
parameter. The inputs to CREATE-DEVICE are two interrupt 
service routines, one of which actually handles device interrupts 
and the other of which handles power failure occurring while the 
driver is running. 

The program then appends ‘ ‘0’ ’ (by convention) to the controller 
name and makes it the name for its own job port. This name can 
then be used by other programs in the system to send output to the 
lineprinter by using a name like lpaO: 


(Create a name for the job’s port) 

device_name : = controller name + ‘O’ ; 
job_port (printerport); 
create_name (job_name, 
device _ name, 
printer port, 
table : = name$local); 
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The program calls a procedure to initialize the device interface and 
calls another procedure, INITIALIZATION-DONE, to inform 
the kernel that it has completed its initialization sequence. Until 
INITIALIZATION—DONE was called, the kernel would not 
start other jobs. This allows a programmer to configure a system 
so that all drivers are initialized before they are needed. 


(Initialize the DMF-32 interface for the line printer) 
initialize, interface; 

(Signal the kernel that we’re done with initialization) 
initialization.done; 


Finally, the program sits in a loop that waits for and accepts a 
circuit request (a message from the i/o runtime code), calls 
dap $ server to handle the circuit, and then breaks the circuit. 


(Now wait for someone who wants to use the printer) 
while true do 
begin 

(Accept the circuit and go process the request) 
accept.circuit (printer.port); 
status : = dap$server (circuit, port: = printer.port, 
open.action : = open_printer, 
put.action : = write.printer); 

(Disconnect the circuit and wait for another one) 

disconnect.circuit (printer.port) 

end 


end; 
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The messages sent and received on the circuit all conform to the 
Data Access Protocol, the interface which is defined in $dap. In 
most device drivers, the function DAPSSERVER is called with 
two kinds of arguments:_ 

• A message port that represents the requestor’s circuit on which 
the $dap module should operate 

• A list of action routines, which perform each of the appropriate 
actions on the specific device (here, routines are supplied for 

“open” and “put”) 

DAPSSERVER applies one of the given action routines to the 
message and returns a status value indicating whether the action 
was successful. 


Dap Action Routine. 

The function WRITE-PRINTER is a function of type dap$put_ 
action. Function types pre-define a function’s parameters and its 
result. In this case, the function has six input parameters and 
returns a status value. The $dap module has exported this function 

type- 


function write_printer of type dap$put_action; 

I+ + 


{Put_action 

i 

: put/write action routine 

\ 

(Inputs: 

( 

( 

1 : 

I : 

I : 

1 

record_access 
record_ number 
record-options 
buffer 

buffer, length 
context 

-record access type 

-record number 

-record options 

-output buffer 

-length of data in buffer 

-driver specific parameter (unused) 

1 

(Outputs: 

return value 

-write status 
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var 


prefix_char: char; 
prefix_count: byte; 
postfix_char: char; 
postfix.count: byte; 
char.count: integer; 
first.char: char; 


Basically, the “write,” or “put,” action is: interpret the first char¬ 
acter in the record, especially if the output file has “fortran- 
type” carriage control; load the device registers with the appro¬ 
priate information; start the transfer; and wait for the transfer to 
complete. A more complete explanation of this carriage control 
treatment can be found in the vms documentation for terminal or 
lineprinter drivers. 


begin 

(These are defaults for prefix and postfix characters and counts} 
prefix_char: = chr(line_feed); 
prefix_count: = 1; 

postfix_char: = chr(carriage_return); 
postfix.count: = 1; 

char.count: = buffer.length; 

(Zero length buffer?} 
if buffer, length = 0 then 
mapped .address, long : = 0 
else 
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(Check for fortran-type carriage control) 
if fortran then 
begin 

first_char: = substr(buffer t, 1,1); 

(Check for double spacing) 

if first_char = ‘O’ then prefix.count: = 2; 

(Check for formfeed) 

if first.char = ‘1 ’ then prefix_char: = chr(form_feed); 

(Check for overstrike) 

if first.char = *+’ then prefix.count: = 0; 

(Don’t output first character) 
char.count: = char.count - 1; 
end; 


(Now start setting up the interface registers) 
repeat 

regiont.powerfail: = false; 

if buffer, length < > 0 then 
begin 

(Map the user’s buffer (or remap it if a powerfail occurred)) 
unibus.map (dev : = printer.device, 
buffer : = buffer t, 
buffer.size : = buffer.length, 
unibus.address : = mapped.address.long); 

(Don’t output first character for fortran carriage control) 
if fortran then 

mapped.address.long : = mapped.address.long + 1; 
end; 
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(Synchronize with device} 
disable.interrupt (printer, ipl); 


The procedure WRITE-REGISTER lets you specify a record 
representing a device register (the first argument), followed by 
assignments to the record’s fields (the second and subsequent 
arguments). Any fields not specified are zeroed. For all fields that 
are specified, the procedure constructs an output value of the 
appropriate length and format and writes it into the register with a 
single instruction. 


(Set Indirect register number in csr} 

write.register (register.locationt.control, format: = true, irnum : = 2); 

(Write out to the postfix and prefix indirect registers (2 & 3)} 
write, register (register_ locationt. prefix, 
chr.cnt: = prefix_count, 
ps.chr: = prefix_char); 
write, register (register.locationt.suffix, 
chr.cnt: = postfix_count, 
ps.chr: = postfix.char); 

(Write out the low order 16 bits of the mapped address) 

write.register (register.location T .dma.low, mapped.address.lowl6); 

(Write out the DMA character count} 

write.register (register.location t .dma.count, -char.count); 

(Write out indirect register 6 which contains several various things} 
write.register (register.location T ,dma_h_char, 
dma_high : = mapped_address.high2, 
auto.cr: = default.auto.cr, 
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ff.lf: = defautt_ff_lf, 
npc_acc : = default.npc_acc, 
wrap : = default.wrap, 
lc_uc : = default. Ic_uc); 

{Register 7 contains info about paper size) 
write.register (register.location t .Ip.format, 
p_height: = lines, per. page, 
p.width : = page.width); 

{Raise to powerfail ipl for powerfail check) 

disable.interrupt (ipl$_power); 
if not region t .powerfail then 
begin 

{Now set the device enable bit to start the transfer) 

{Reading csr and setting appropriate bits preserves csr contents) 

Ipt.csr : = read.register (register.location t .control); 
lpt_csr.print.en : = true; 
lpt_csr.int.en : = true; 

write.register (register.location t .control, Ipt.csr); 
region t .device.busy : = true; 
enable, interrupt; 


The WAIT-ANY procedure will put the driver process in the 
waiting state until the interrupt service routine calls 
SIGNAL-DEVICE. 

{Now we wait for the transfer to complete) 

wait.any (printer.device); 

end 
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else 

enable, interrupt; 
if buffer.length < > 0 then 

{Unmap the buffer (even if powerfail... it gets remapped later)) 
unibus_unmap (dev : = printer-device, 
buffer : = buffer t, 
buffer-size : = buffer-length, 
unibus_address : = mapped_address:integer); 

until not region T .powerfail; 

{Indicate success or failure) 

if region t .csr_response.Ipt_err then 
write-printer: = dap$k_device-error 

else 

write_printer: = dap$k_success 
end; {End of action routine.) 


When the controller finishes with the request, an interrupt 
occurs. The interrupt service routine reads the contents of the 
device register into the communication region so that the m ain 
driver program can access the information. It then calls 
SIGNAL-DEVICE so that the main program can proceed with 
the WRITE-PRINTER action. 


interrupt-service printer-interrupt (xreg : register_ptr; 
comm : region-ptr); 

begin 

{Read the CSR and indirect registers 0 and 1 ( 
with comm t, x reg t do 
begin 

csr_response : = read-register (control); 
bytes_output: = read-register (bytes_out); 
lines-output: = read-register (lines_out); 
device-busy : = false; 
end; 

signal-device 


end; 
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Another interrupt service routine is called by the kernel when a 
power failure interrupt occurs. It performs a controlled reinitial¬ 
ization of the lineprinter interface. 


interrupt.service powerfaiL recovery (xregister: register.ptr; 
comm : region, ptr); 

var 

combo.board.csrO: combo.csrO; 
begin 

with comm T, xregister T do 
begin 


4 


(Reset the interface) 

write.register (control, reset: = true); 


powerfail: = true; 

if device.busy then 
signal.device; 

end; (with) 
end; 
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